The present invention relates generally to automated systems for establishing proof of insurance, and more specifically to a World Wide Web based system for defining, generating, and managing certificates of insurance.
As it is generally known, certificates of insurance are documents that establish proof of insurance, and are sometimes referred to simply as “certificates” herein. Certificates are required of service suppliers, contractors, manufacturers mortgagees, lessors, users of others' premises and others. A certificate of insurance certifies that an entity or person has purchased insurance coverage, and can frequently also confirm specific details about that insurance that benefit the requestor, who is referred to as the “certificate holder”.
In general, the four parties that are involved with a certificate of insurance are as follows:    1. “Certificate Holders”: Those who request proof of another's (the “Insured”) insurance.    2. “Insured”: Those who must provide the Certificate Holder with evidence of their insurance coverage, typically with a certificate.    3. “Producers”: Those whose sell insurance policies to the Insured and issue the certificates. Insurance agents and brokers are examples of Producers. In some cases, an insurance company sells insurance directly to an Insured and issues its own certificates directly.    4. The “Insurer(s)”: Insurance companies that are shown on the certificate.
In today's practice, the Certificate Holder asks the Insured for a certificate. The Insured then asks the Producer for the certificate. The Producer in turn issues the certificate on behalf of the Insurer. Copies of the certificate are distributed to the Certificate Holder, Insurer, and frequently the Insured. Producers may employ various types of existing certificate management systems. The level of automation in such existing systems varies widely, and may include anything from a nationally deployed computer program and database for a multinational broker, to word processing. A significant drawback of existing Internet based certificate automation systems is that they operate to transfer the workload from the Producer to the Insured, not to the Certificate Holder.
The traditional certificate issuance process requires the Certificate Holder to call, mail or fax a message to the Insured to request a certificate. The Insured then must call, mail or fax a request to the Producer. The Producer then issues the certificate to the Certificate Holder, and also sends copies to the Insurer(s), and frequently also to the Insured. In some cases, the Insured parties may simply tell the Certificate Holders to call the relevant Producer directly to obtain the certificate.
For example, a general contractor may be liable under certain circumstances if a sub-contractor does not have adequate insurance. Since the general contractor would like to avoid such liability, the following sequence of events would be likely to occur:    1. The general contractor asks each sub-contractor for a certificate of insurance with specified limits and a specific “additional insured” wording.    2. The sub-contractors ask their respective Producers to issue the certificates. The sub-contractors each provide the relevant information to their respective Producers, including the name and address of the general contractor, specified limits and the “additional insured” wording.    3. The Producers ask the relevant Insurer(s) to authorize the specific wording.    4. The Insurers authorize the specific wording.    5. The Producers issue the certificates with the specified limits and wording directly to the general contractor with copies sent to the Insurers and sub-contractors.    6. The general contractor checks the certificates for accuracy, and records the information they contain, for example in a database. The general contractor further makes records of the expiration dates of each of the policies referenced on the certificates for renewal certificate purposes.    7. The Insurers file the certificates for later use in processing claims and cancellation.
In another example of the traditional certificate issuing process, a drug store chain may want to make certain that a pharmaceutical manufacturer has product liability insurance. In such a situation, the following events may occur:    1. The drug chain requests a certificate from the pharmaceutical manufacturer and states that it must include a specific type of coverage, such as what is generally referred to as “Broad Form Vendors'” coverage.    2. The pharmaceutical manufacturer asks their Producer to issue the certificate. The pharmaceutical manufacturer provides relevant information to the Producer, including the name and address of the drug chain, and indicates that the certificate must include the required type of coverage.    3. In the case where the insurance policy of the pharmaceutical manufacturer automatically provides the required coverage (some do and some do not), the Producer issues the certificate directly to the drug chain, and provides copes to the Insurer and pharmaceutical manufacturer.    4. The drug chain checks the certificate for accuracy, records the information, for example in a database, and records the expiration dates of the policies in a diary for renewal certificate purposes.
5. The Insurer(s) file the certificate for later use in claims and cancellation.
As described in the examples above, Certificate Holders, Producers and Insurers each generally maintain their own record of issued certificates. In addition, both the Certificate Holder and Producer keep their own renewal records. Since each entity maintains their own independent records, they frequently also maintain their own database.
The existence of multiple, uncoordinated databases results in significant overhead costs. For example, a certificate may contain a clause stating that the Insurer will “endeavor” to notify the Certificate Holder if the policy is cancelled. Occasionally, the Producer eliminates the word “endeavor”, making such notification obligatory. No existing system is available which allows an insurer to automatically issue cancellation notifications. Additionally, a certificate can influence the settlement of a claim, and insurance company claim adjusters accordingly may require access to issued certificates. Again, no existing system is available which effectively automates a claim adjuster's work in locating the certificate.
Furthermore, existing systems fail to effectively automate the certificate renewal process. Most insurance policies are annual and many of the relationships between the Insured and Certificate Holders are long term and occasionally, perpetual. The certificate renewal process using existing systems usually requires the Producer to send a list of previously issued certificates to the Insured for review. For those with large volumes, this process is so complex that it is usually easier for the Producer to issue renewal certificates to any entity that previously received a certificate. This process can continue for years and some Insureds issue thousands of unnecessary and potentially inaccurate certificates.
Moreover, some certificates require approval of the Insurer and some require that the insurance policy itself be changed or endorsed to reflect conditions stated on the certificate. In existing systems, the resulting process can be extremely cumbersome. For example, the Certificate Holder might first request a certificate from the Insured. The Insured would then place a request to the Producer who then must ask the underwriter to endorse the policy. The underwriter then notifies the Producer that the endorsement is bound and the Producer issues a certificate and sends or faxes it to the Certificate Holder, Insurer and occasionally, the Insured.
Thus it is seen that existing Certificate of Insurance systems result in a time consuming, unwieldy processes. Accordingly, it would be desirable to have a system which advantageously addresses the above described shortcomings.